第11章 より効果的なアジャイル:品質
開発チームが1時間作業するたびに、欠陥がいくつか紛れ込む
さすがに闇が深すぎる気はするw
基本原則:完成の定義を作成し、使用する
DoD 、うちの現場でも定義したい!自分の作業は明確でも、それがどうリリースされていくのか、今どういう状況なのかがよくわかっていない。(JOINしてから間もないので・・・実際にはもうあるかも・・・探してみよう)
自社にDoDを定義していないスクラムチームがいくつか存在する。(テストを別工程で行うチーム、運用担当で軽微なタスク担当チームは定義してないことが多い(当社調べ))ただ、DoDを定義した方が、品質の認識を合わせやすいので、なんとか定義したい気持ち
↑定義しない理由が気になります!(書いてくれていた...!)
DoDにより、アイテムのQA作業がその他すべての作業の近くで実行できるようになるからだ。
QAと近くで仕事をしたことが無いので、これは体験してみたい。
QA作業なので、開発者がやる内容もふくんでいそうですね
「コードのレビューが完了している」といった基準は活動を説明している。「コードがコードレビューを通過している」といった基準はエビデンスである
活動よりもエビデンスをというのは分かる。(活動自体ではなく、活動を通して出せたインパクトをエビデンスとして残しておこうという話だと理解)ただ、↑の例は前者の書き方だと後者の書き方に比べてどのような問題が引き起りやすいのか分からなかった。。。
👆同意
後者だと、何かしらのフィルター(基準)をクリアしているイメージがあります。適切な表現が他にありそうですが。
前者は「レビューは完了した(修正あり)」の状況なのか、そうでないのかが曖昧なのが良くないってことでしょうかね。
ちなみに、自分の所のDoDは「レビューが完了すること」と書かれている。
多くの場合、完了した作業は本番稼働環境にデプロイすることになる。場合によっては、これが適切ではない場合がある。たとえば、・・・などがそうである。
高頻度で本番稼働環境にデプロイすることが適切ではないケースの例が当たり前すぎるために、ここの文章が何を意味するのかがよくわからなかった。(考え無しにすぐにリリースするなということ?)
アジャイル開発との関連が深いとはいえ、筆者はペアプログラミングをより効果的なアジャイルプラクティスとして重視することをためらってきた。なぜなら、筆者の経験では、ほとんどの開発者が作業をペアで行うことを望まないからだ。
わかる・・・でもペアプロしたい。ペアプロは集中力が上がるし続くし、チームメンバーの結束力も強まるので、とても良い。常に必ずペアプロが良いとは思ってませんが、「自由にペアプロして良い」という空気を作っていけたら良いなと思ってる。
意見が幅広く分かれているから、モブプロ/スウォーミングを強く支持しない(選択的に実践すべきorニッチなプラクティス)というのはマコネルっぽい。
並行で担当者が個人ごとにコーディングするやり方なので、コードレビューでレビュー待ちが山積みに…ペアプロ取り入れて早い段階で軌道修正できるようにしていきたいなぁとは思いつつも、一人でやりたい人もいたりでなかなか広まらず。部分的にお試しでやりながら広めていきたい。
明確な完成の定義(DoD)は、欠陥の挿入と検出の間のギャップを最小化するのに役立つ。DoDにより、アイテムのQA作業がその他全ての作業の近くで実行できるようになるからだ。
DoDを使ったことがないので、ギャップを最小化するために、どう運用すると良いのかあまり実感がわかない。
欠陥と挿入の検出のギャップを埋める他のやり方や、スプリント内により確実にアイテムを完了させる方法は他にもあると思うけれど、一番最初に紹介されているということは大事なのかな。
欠陥挿入と検出のギャップを(プロジェクトの都合で仕方なく)なくそうとした結果、コストがかかる方法にも手を出したことがある。
ギャップを最小化しようとする際に、他の観点も忘れないようにしたい。
そしてギャップを最小化する嬉しさの度合も把握しておきたい。。。(ギャップの嬉しさが、時間軸においてどのように変化していくのか、をあまり実感していない)
11.6推奨リーダーシップアクション
検査
QA活動と、欠陥がいつどこで検出されるのかを確認する。アジャイルプラクティスを利用することで、より多くの欠陥をより早い段階に検出できるかどうかを判断する。
WFなので結合テスト以降でもで欠陥が見つかることがそこそこあります。(今進めてる案件でもシステムテストで改修を予定していなかったところに修正が必要なところが見つかってしまった…)
確認している。アジャイルをはじめてからは目に見えて早い段階で欠陥に気が付けるようになった。agile testing condensedに記載されていたプラクティスを一通りやったが、実例マッピングはかなり効いた印象。
最近の開発だと初回リリース直前にQAが一気にガガーっと何かしてくれていた(らしい
ローカルでのUnitTest、GithubAction?でのCI 、Jenkins、stable 環境での QA さんの試験で担保しています。QA さんの試験で欠陥が抽出されたところはまだ観測できていないです。
プロジェクトの未解決の欠陥リストを確認する。未解決の欠陥はいくつあるだろうか。その数は、プロジェクトで修正されていない潜在的な欠陥をバックログに積み上げていることを暗示しているだろうか。
どれも発生確率が極小のものばかりだが、これはなかなかの数がある。。。顧客に話していないこともあってバックログに積み上げることが中々難しく、扱いに苦戦している。(関連機能を直す際にしれっと直すことが多い)
チームに完成の定義(DoD)を見せてもらう。明文化したDoDはあるだろうか。チームはそのDoDを使用しているだろうか。DoDの内容を総合すると「リリース可能な」状態になるだろうか。
DoDはあり、運用されている。総合すればリリース可能な状態にもなる。
複数のアイテムを跨ぐものってどうしているんだろうか。非機能要求とかは文書の量の関係で省いている?
チームがプロジェクトでの手戻りの割合を計測し、プロセス改善作業のためのデータとして活用しているかどうかを調査する。
計測の章でも書いたが、手戻りの定義の認識合わせに頓挫して計測していない。
手戻りの割合(?)かどうかわかりませんが、プロセスのチェックとして各バグに対してどの工程で検出すべきだったかくらいは確認していますね。
チームが今行っていることを「リリース可能な」状態にするにあたってどのような妨害が存在するだろうか。チームがそうした妨害に対処することをどのように支援できるだろうか。
スプリントレビューに参加しないステークホルダーの最終リリース判定会が妨害要素になることが多かったため、最終リリース判定会の前段階から継続的にリリース判定会のようなものをそのステークホルダーのために行った。
ある機能がまとまってないとステークホルダーからリリース許可がおりない場合、テストも最後にやろう的な雰囲気なりやす気がする(ただし、観測数2/2(当社調べ))。なので、こまめにリリースできるよう環境をつくることは精神的にも大切と思った。
適応
欠陥がいつどこで検出されるのかを評価し、その上で品質保証のプラクティスを前倒しする計画を立てる。
これは既にできている
感性が必要になる部分のテストが形式知化されておらず、とにかく早くやるくらいしかないのが辛い。
プロジェクトの未解決欠陥の数を減らし、その数を低く保つ計画を立てる。
できていない。顧客に説明しても、新機能リリースは止めるなと言われるので難しいなあ。。
あまりしたことがないけど、勝手にそこそこ治していたからかも知れない。
チームと協力して、プロジェクトの手戻りに投入する作業量を計測し、作業全体での割合を計算する。この割合をプロセス改善作業の一部として監視する。
計測の所で手戻り率の概念を読んでもピンとこなかったのでまだやっていない。
47機関だと大体30%を突っ込んでいる
チームが今行っていることを「リリース可能な」状態にするにあたって妨害となっているものを取り除く。
チーム全員がストレスを感じる部分が別にまだあるためしばらく着手できていないが、いずれはやりたい。
47機関だと職位が多様なので、適切な職位の人がいい感じにパフォームするようになっている。